The Intellectual Property (IP) cores may be circuitry, embedded memories, communication links, a processor, etc., having self-contained designed functionality. Additionally, IP cores may be implemented in a variety of ways, and may be fabricated on a single integrated circuit such as a System on a Chip.
Various interconnect protocols exist such as Open Core Protocol™ (OCP), Peripheral Component Interconnect, Media Independent Interface, and Advanced High-performance Bus (AHB). Some interconnect protocols define a bus-independent interface for IP cores. System-on-a-Chip IP core interfaces can be described in this consistent format, such as a simple peripheral core, a high-performance microprocessor, or even an on-chip communication subsystem. Unique for each core, the IP core interface includes all of the signals required to describe IP core communication including data flow, control, and verification and test signals. An IP core interface assists system verification and testing by providing a firm boundary around each IP core that can be observed, controlled, and validated.
System on Chip (SoC) designs use bus protocols for high performance data transfer among the Intellectual Property cores located on that chip. These interconnect protocols may incorporate advanced features such as pipelining, burst and split transfers, etc. Many of the modules connected to the bus are vendor provided IP cores in which the designs for these IP cores may not be made available. The SoC bus protocol between these IP cores as well as the functionality provided by each IP core needs to be debugged and have various design values verified.
An approach to verifying digital hardware during a simulation run may be to utilize software monitors and software checkers written in C++. The monitor serves the purpose of collecting data from a hardware interconnect and making it available to a checker. An interconnect can be a set of wires that carries data and control information between two IP cores. The checker may model the functionality of an IP core using the data from the monitors as input. The checker communicates to the monitor that it needs data and establishes a single location to send that data. These monitors collect data from a hardware interconnect that is attached to the IP core. The checker compares the expected results of the IP core it is modeling to the actual data by using the data collected through the same monitors. Typically, a monitor exists for each of the interfaces of an IP core. The data collected from each of these monitors is passed to the checker for that specific IP core. A monitor may also be located inside or external to an IP core.
This typical approach quickly becomes problematic in hardware designs where several IP cores are connected via hardware interconnects. A monitor on each interconnect could potentially have to provide various items of data to several checkers. For instance, a monitor might need to provide data to a master core checker, a slave core checker and a protocol checker all at the same time. The typical approach is that a monitor does not share data required by several checkers. Each checker has its own monitor to retrieve the needed data.
Further, the typical approach may have protocol monitors write protocol data to a file during a simulation run. After a simulation run completes, then a series of tools run to analyze the data contained in the trace files to detect errors and display performance data. This process lacks the ability to check for errors in a design during a simulation run. It may be desirable to terminate a simulation a few clock cycles after an error occurs in a hardware design in order to decreases costs both in terms of required CPU time and time between successive simulation runs.